RedCap Rel-18

 RAN1#109-e

9.6       Study on further NR RedCap (reduced capability) UE complexity reduction

Please refer to RP-213661 for detailed scope of the SI.

R1-2205575        Session notes for 9.6 (Study on further NR RedCap (reduced capability) UE complexity reduction)     Ad-hoc Chair (CMCC)

R1-2204058        Work plan for Study on further NR RedCap UE complexity reduction               Rapporteur (Ericsson)

R1-2203121        Skeleton for TR 38.865 (Study on further NR RedCap UE complexity reduction)               Rapporteur (Ericsson)

[109-e-R18-RedCap-01] – Johan (Ericsson)

Email discussion and approval of TR skeleton for Rel-18 SI on further NR RedCap (reduced capability) UE complexity reduction by May 13

R1-2205431        FL summary for TR skeleton for Rel-18 SI on further NR RedCap UE complexity reduction       Moderator (Ericsson)

R1-2205432        Draft skeleton for TR 38.865 (Study on further NR RedCap UE complexity reduction)           Rapporteur (Ericsson)

Decision: As per email decision posted on May 20^th, the draft skeleton is endorsed in principle. TR 38.865 is endorsed as v0.0.1 in R1-2205693 as basis for further updates.

9.6.1        Potential solutions to further reduce UE complexity

R1-2203054        Discussion of complexity reduction techniques for RedCap UEs in Rel-18               FUTUREWEI

·        Proposal 1: Reuse the complexity breakdown for a reference NR device for the complexity reduction techniques in Rel-18.

·        Proposal 2: Define a baseline Rel-17 RedCap UE that supports a maximum 20 MHz bandwidth, one Rx branch, one MIMO layer, and a maximum DL modulation order of 64QAM.

Decision: The document is noted.

R1-2204809        On solutions to further reduce UE complexity        Intel Corporation

Proposal 1: if RBW-A or RBW-B is supported

·        Inter-BWP hopping may be considered to improve link level performance for PDSCH, PUSCH and PUCCH with repetitions.

·        RAN4 input on the length of inter-BWP switching time for F-RedCap UE is needed.

Proposal 2: if RBW-A or RBW-B is supported

·        Study potential solutions to increase the number of CCEs that can be used for PDCCH transmission.

o   Increase the maximum number of symbols of CORESET

o   CORSET bundling/repetition

Proposal 3: for RBW-C operation

·        A DL or UL BWP can have a bandwidth of up to 20MHz

·        A UE can support both localized and distributed PDSCH/PUSCH transmission within the UL BWP

Proposal 4: Down-selection of a design for F-RedCap UE among the options of RBW-A/B/C and limiting peak data rate.

Proposal 5: Consider the limitation on the peak data rate together with options RBW-A/B/C for BW reduction.

Proposal 6: The total number of REs allocated for PDSCH or PUSCH transmission can be limited, with impact on the targeting peak data rate required by the SID. 

Proposal 7: It is preferred to relax the UE processing time for PDSCH and/or PUSCH and/or CSI.

Proposal 8: Study whether it is beneficial to reduce the maximum number of HARQ processes.

Proposal 9: Consider limiting DL modulation to 64QAM and UL modulation to 16QAM.

Proposal 10: Half-Duplex FDD Type B can be considered for F-RedCap UE.

Proposal 11: Consider limiting the frequency allocation to no more than 25 PRBs for all broadcast/units PDSCH transmission.

Proposal 12: Early identification of F-RedCap UE should be supported.

Proposal 13: Consider limiting the number of broadcast and/or unicast PDSCHs in a slot, or process the broadcast and/or unicast PDSCHs with limited PRBs or REs supported by F-RedCap UE.

Decision: The document is noted.

R1-2203117         Potential solutions for further RedCap UE complexity reduction            Ericsson

R1-2203169         Discussion on potential solutions to further reduce UE complexity         Huawei, HiSilicon

R1-2203338         Discussion on potential solutions to further reduce UE complexity         Spreadtrum Communications

R1-2203473         Discussion on solutions to further reduce UE complexity in Rel-18        CATT

R1-2203572         Techniques to further reduce the complexity of RedCap devices             vivo, Guangdong Genius

R1-2203600         Discussion on further RedCap UE complexity reduction           ZTE, Sanechips

R1-2203661         Discussion on potential solutions to further reduce UE complexity         China Telecom

R1-2203761         Further reduce UE complexity for eRedCap Panasonic Holdings Corporation

R1-2203827         Discussion on the potential complexity reduction solutions for further UE complexity reduction              xiaomi

R1-2203917         Further UE complexity reduction for eRedCap            Samsung

R1-2203995         Solution study on further reduced UE complexity       OPPO

R1-2204038         Further UE Complexity Reduction  Nokia, Nokia Shanghai Bell

R1-2204176         Discussions on potential solutions to further reduce UE complexity       Sharp

R1-2204255         On further RedCap UE complexity reduction features Apple

R1-2204315         Discussion on  further reduced  UE complexity           CMCC

R1-2204389         Discussion on potential solutions for further UE complexity reduction  NTT DOCOMO, INC.

R1-2204437         Discussion on potential solutions to further reduce UE complexity         NEC

R1-2204504         Potential solutions to further reduce UE complexity   Lenovo

R1-2204582         Discussion  on potential solutions to further reduce UE complexity        Transsion Holdings

R1-2204626         Discussion on potential solutions for further UE complexity reduction  LG Electronics

R1-2204714         On potential solutions to further reduce UE complexity            MediaTek Inc.

R1-2204747         On further complexity reduction of NR UE   Nordic Semiconductor ASA

R1-2204829         Potential techniques for further RedCap UE complexity reduction          InterDigital, Inc.

R1-2204879         Considerations for further UE complexity reduction   Sierra Wireless. S.A.

R1-2205043         Further complexity reduction for eRedCap device      Qualcomm Incorporated

[109-e-R18-RedCap-02] – Johan (Ericsson)

Email discussion on further UE complexity reduction by May 20

-        Check points: May 18

R1-2205281        FL summary #1 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From May 12^th GTW session

Agreement

For cost reduction estimation, the detailed cost breakdown for the Rel-15 reference NR devices (as provided in Table 6.1-1 in TR 38.875) is reused.

Agreement

For comparison with a Rel-17 baseline when evaluating the potential Rel-18 UE complexity reduction features,

• The Rel-17 RedCap UE supports 20 MHz, 1 Rx, 1 layer, DL 64QAM, UL 64QAM, FDD or TDD.
• In addition, optional results for the following comparisons can also be reported:
• Results for HD-FDD UEs
• Results for UEs with 2 Rx
• In all comparisons, the UEs being compared have the same number of antenna branches, the same number of layers, the same maximum supported modulation order, and the same duplex mode (among HD-FDD, FD-FDD, and TDD).

Decision: As per email decision posted on May 14^th,

Agreement

·        The following options for relaxed UE processing timeline will be studied:

o   Option PT1: Relaxation of UE processing time for PDSCH/PUSCH in terms of N₁ and N₂

o   Option PT2: Relaxation of UE processing time for CSI in terms of Z and Z’

·        UE complexity reduction estimates for relaxed UE processing timeline are only reported for combinations with UE bandwidth reduction or UE peak rate reduction.

R1-2205433        FL summary #2 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From May 17^th GTW session

Agreement

• The following options for further UE bandwidth reduction can be studied:

• Option BW1: Both RF and BB bandwidths are 5 MHz for UL and DL.
• Option BW3: 5 MHz BB bandwidth only for PDSCH (for both unicast and broadcast) and PUSCH with 20 MHz RF bandwidth for UL and DL. The other physical channels and signals are still allowed to use a BWP up to the 20 MHz maximum UE RF+BB bandwidth.
• In addition, optional results for the following option can also be reported:
• Option BW2: 5 MHz BB bandwidth for all signals and channels with 20 MHz RF bandwidth for UL and DL.
• At least the following cases are studied:
• The resource allocation spans a bandwidth of maximum 5 MHz.
• The same option is used for UL and DL.
• The same option is used for idle/inactive and connected mode.
• It is FFS whether to study other cases.
• Note: As part of study of above options, it is not precluded to indicate that an observation is relevant for UL only or DL only.

Agreement

• The following options for further UE peak rate reduction can be studied:
• Option PR1: Relaxation of the constraint   for peak data rate reduction.
• Option PR2: Restriction of maximum TBS for PDSCH and PUSCH.
• Option PR3: Restriction of maximum number of PRBs for PDSCH and PUSCH.
• At least the following cases are studied:
• The studied peak rate reduction applies to both UE-specific (unicast) and common (broadcast) channels.
• The resource allocation spans a bandwidth of maximum 20 MHz (maximum UE channel bandwidth).
• The same option is used for UL and DL.
• The same option is used for idle/inactive and connected mode.
• It is FFS whether to study other cases.
• Note: As part of study of above options, it is not precluded to indicate that an observation is relevant for UL only or DL only.

Decision: As per email decision posted on May 19^th,

Agreement

·        The impact on memory size/cost/complexity (external to the RF and BB parts) from the studied UE complexity reduction features can be considered in the study.

o   This potential impact will not be included in the quantitative UE complexity reduction estimates.

o   L2 buffer size assumptions can be based on TS 38.306 clause 4.1.4 (“Total layer 2 buffer size for DL/UL”).

o   FFS whether/how to capture in the TR

Agreement

For each potential Rel-18 further UE complexity reduction feature, at least the following aspects will be studied:

·        UE complexity reduction

·        Performance impacts [details FFS]

·        Network deployment and coexistence impacts [details FFS]

·        Specification impacts

Agreement

·        The restricted number of PRBs in Option PR3 is a hardcoded limit.

Agreement

• In Option PT1, the relaxation factor for N1 and N2 is 2.
• In Option PT2, the relaxation factor for Z and Z’ is 2.
• The combination of Options PT1 and PT2 is also studied.

R1-2205434        FL summary #3 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From May 19^th GTW session

Agreement

·        For Options BW1,

o   For 15 kHz SCS, 25 contiguous RBs are assumed to fit within the 5 MHz.

o   For 30 kHz SCS, 11 contiguous RBs are assumed to fit within the 5 MHz.

o   Larger number of RBs that fit within 5 MHz can optionally be studied.

·        For Options BW2,

o   For 15 kHz SCS, 25 contiguous RBs are assumed to fit within the 5 MHz.

o   For 30 kHz SCS, 11 contiguous RBs are assumed to fit within the 5 MHz.

o   Larger number of RBs that fit within 5 MHz can optionally be studied.

·        For Options BW3,

o   For 15 kHz SCS, 25 contiguous RBs are assumed to fit within the 5 MHz.

o   For 30 kHz SCS, 11 contiguous RBs are assumed to fit within the 5 MHz.

o   Larger number of RBs that fit within 5 MHz can optionally be studied.

·        Relevant assumptions (e.g., regarding potential scheduling restrictions) should be reported.

Agreement

·        For Option PR1,

o   The relaxed constraint is 1 (instead of 4).

o   Other values for the relaxed constraint that meet the 10-Mbps peak rate target can optionally be studied.

o   The parameters (, , ) [38.306] can be as in Rel-17 RedCap.

·        For Option PR2,

o   For 15 kHz SCS, the maximum TBS is 10000 bits per TB and per slot.

o   For 30 kHz SCS, the maximum TBS is 5000 bits per TB and per slot.

·        For Option PR3,

o   For 15 kHz SCS, the maximum number of RBs is 25.

o   For 30 kHz SCS, the maximum number of RBs is 11.

o   Other number of RBs that meet the 10-Mbps peak rate target can optionally be studied.

·        Note: It is not precluded to report results also for other values.

·        Relevant assumptions (e.g., regarding potential limitations of the TBS sum in case of more than one simultaneous TB) should be reported.

Agreement

·        UE complexity reduction is studied for the following combinations:

o   Reference case (Rel-17 RedCap UE)

o   BW1 + PT1 + PT2

o   BW3 + PT1 + PT2

o   PR1 + PT1 + PT2

o   PR3 + PT1 + PT2

·        In addition, optional results for the following combinations can also be reported:

o   BW1 + PT1

o   BW3 + PT1

o   PR1 + PT1

o   PR3 + PT1

o   BW2 + PT1 + PT2

o   PR2 + PT1 + PT2

Final summary in R1-2205435.

Note: Draft updated spreadsheet templates to be provided by the feature leads, for discussion and agreement

·        Dates:  13^th – 17^th June

9.6.2        Simulation needs and assumptions

R1-2203118        Simulation needs and assumptions for further RedCap UE complexity reduction               Ericsson

·        Proposal 1: The methodology in TR 38.875 is reused for the determining the target performance for coverage recovery in the Rel-18 eRedCap SI.

·        Proposal 2: Discuss whether the UE antenna efficiency loss of 3 dB that was assumed for Rel-17 RedCap UEs in FR1 in TR 38.875 should be included in link budget evaluations in the Rel-18 eRedCap SI.

·        Proposal 3: RF+BB bandwidth reduction to 5 MHz as well as BB-only bandwidth reduction to 5 MHz for data channels should be considered in the link budget evaluations.

·        Proposal 4: The target data rate for 5-MHz RedCap UE in DL and UL is the scaled value of the Rel-17 RedCap UE by a factor of 0.25 if UE antenna efficiency loss (3 dB) is assumed and by a factor of 0.5 if there is no assumption of the antenna efficiency loss.

Decision: The document is noted.

R1-2203055         Simulations for the Rel-18 RedCap SI           FUTUREWEI

R1-2203170         Discussion on simulation needs and assumptions        Huawei, HiSilicon

R1-2203339         Discussion on evaluation needs and assumptions for eRedCap Spreadtrum Communications

R1-2203474         Views on evaluation needs based on different assumptions       CATT

R1-2203573         Discussion on potential simulation for eRedCap         vivo, Guangdong Genius

R1-2203601         Evaluation requirements for Rel-18 RedCap UE         ZTE, Sanechips

R1-2203828         Simulation needs and assumptions on further NR Redcap UE complexity reduction               xiaomi

R1-2203918         Evaluations for eRedCap  Samsung

R1-2203996         Simulation and evaluation for RedCap enhancement  OPPO

R1-2204039         Evaluation assumptions for further complexity reduction          Nokia, Nokia Shanghai Bell

R1-2204316         Discussion on simulation needs and assumptions        CMCC

R1-2204390         Discussion on simulations and assumptions for further UE complexity reduction NTT DOCOMO, INC.

R1-2204505         Evaluation needs and assumptions for further NR RedCap       Lenovo

R1-2204583         Discussion on simulation needs and assumptions        Transsion Holdings

R1-2204627         Discussion on simulation needs for further UE complexity reduction     LG Electronics

R1-2204715         On simulation needs and assumptions for RedCap UEs             MediaTek Inc.

R1-2204810         On simulations for further reduced UE complexity     Intel Corporation

R1-2204830         Simulation needs for further RedCap UE complexity reduction InterDigital, Inc.

R1-2205044         Evaluation for eRedCap SI               Qualcomm Incorporated

[109-e-R18-RedCap-03] – Shinya (NTT DOCOMO)

Email discussion on simulation needs and assumptions by May 20

-        Check points: May 18

R1-2205257        FL summary #1 on simulation needs and assumptions for further reduce UE complexity          Moderator (NTT DOCOMO)

From May 12^th GTW session

Agreement

·        At least the option of RF+BB BW reduction to 5MHz is considered for coverage evaluation

o   FFS whether/which other options are also considered

o   FFS which DL/UL Channels of all the DL/UL channels are evaluated

Decision: As per email decision posted on May 14^th,

Conclusion

·        SLS evaluation for network capacity and spectral efficiency is not conducted in Rel-18 RedCap SI.

R1-2205416        FL summary #2 on simulation needs and assumptions for further reduce UE complexity          Moderator (NTT DOCOMO, INC.)

From May 17^th GTW session

Agreement

·        Evaluation methodology and assumption in Clause 6.3 in TR 38.875 is reused for coverage evaluation of reference UE and Rel-17 RedCap UE.

o   Note: It is up to each company whether to reuse the LLS results

Agreement

·        Coverage for the following channels is evaluated for “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”

o   SIB1

o   PBCH

o   PDCCH CSS

o   [Msg4]

o   Following channels can be optionally evaluated

§  PUSCH

§  PUCCH 2bits

§  PUCCH 11bits

§  PUCCH 22bits

§  PRACH

§  PDSCH

§  PDCCH USS

§  Msg2

§  Msg3

·        Evaluation methodology and assumption in Clause 6.3 in TR 38.875 is reused for coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels” by default, except for, UE bandwidth, cell edge data rate, and small form factor degradation

o   FFS which evaluation assumption should be updated for the above channels

Decision: As per email decision posted on May 19^th,

Agreement

·        Following evaluations are not conducted in Rel-18 RedCap SI

o   Latency

o   Throughput

o   Power saving gain

R1-2205521        FL summary #3 on simulation needs and assumptions for further reduce UE complexity          Moderator (NTT DOCOMO, INC.)

From May 19^th GTW session

Agreement

·        Coverage of Msg4 can be optionally evaluated for “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”

Agreement

·        For coverage evaluation of Rel-17 and Rel-18 RedCap UEs, only 1 Rx branch is assumed.

o   Note: it does not mean that 2Rx is precluded for Rel-18 RedCap UE

Agreement

·        For coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, following parameters are used.

o   Note: Rural scenario at 0.7 GHz, Urban scenario at 2.6 GHz, and Urban scenario at 4 GHz (optional) are considered.

Agreement

·        For coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, target data rates are

o   FR1 Rural: 250 kbps on DL and 25 kbps in UL

o   FR1 Urban: 500 kbps on DL and 250 kbps in UL

o   Note: The target data rates are the scaled value in the Rel-17 RedCap SI by a factor of 0.25

Agreement

·        3dB antenna efficiency loss can be optionally assumed for coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”

Agreement (further updated as shown in red – from May 20th GTW)

·        For at least PDCCH USS coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, following revision are assumed

o   For 15KHz SCS, CORESET size is 3 symbols and 24 PRBs, AL is 8.

o   For 30KHz SCS,

§  Opt1: CORESET size is 3 symbols and 6 PRBs, AL is 2 (baseline)

§  Opt2: CORESET size is 3 symbols and 12 PRBs, AL is 4 (optional)

FFS：Use all CCEs of the CORESET Other configurations are also not precluded

Agreement

·        For coverage evaluation of Rel-18 RedCap UE, 1 Tx branch is assumed.

Conclusion

·        Evaluation of PDCCH blocking probability is not conducted in Rel-18 RedCap SI

R1-2205544        FL summary #4 on simulation needs and assumptions for further reduce UE complexity          Moderator (NTT DOCOMO, INC.)

From May 20^th GTW session

Agreement

·        For SIB1 coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, followings are assumed

o   Opt1: SIB1 BW is larger than 5MHz, e.g., 48PRB

§  The UE can receive a part of SIB1 PDSCH at a time. Detail assumption of reception scheme (e.g., puncturing the bits transmitted outside UE BW) is reported by each company.

o   Opt2: SIB1 BW is within 5MHz

o   A TBS of 1256 bits(other size is not precluded)

Note: whether interleaving mapping is assumed depends on companies’ report

Agreement

·        For PDCCH CSS coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, following revision are assumed

o   Opt1: CORESET BW is larger than 5MHz

§  The UE can receive a part of PDCCH at a time. Detail assumption of reception scheme (e.g., puncturing the bits transmitted outside UE BW) is reported by each company.

§  For 15/30kHz SCS, CORESET size is 2 symbols and 48 PRBs, AL is 16.

§  For 30kHz SCS, CORESET size is 2 symbols and 24 PRBs, AL is 8.  Other configurations are also not precluded

o   Opt2: CORESET BW is within 5MHz

§  For 15kHz SCS, CORESET size is 3 symbols and 24 PRBs, AL is 8.

§  For 30kHz SCS,

·        Opt2-1: CORESET size is 3 symbols and 6 PRBs, AL is 2.  Other configurations are also not precluded

·        Opt2-2: CORESET size is 3 symbols and 12 PRBs, AL is 4

Agreement

·        The LLS results of the option of “RF+BB BW reduction to 5MHz for all DL/UL channels” can be reused for the coverage evaluation of other BW reduction options, if applicable.

Agreement

·        For coverage evaluation in Urban scenario at 4 GHz, DL PSD 33 dBm/MHz is baseline and DL PSD 24 dBm/MHz is optional.

Agreement

·        For Msg4 coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, a TBS of 1040 bits is assumed

o   a TBS smaller than 1040 bits can be optionally evaluated and reported by each company.

Agreement

·        For PRACH coverage evaluation of “Rel-18 RedCap UE with RF+BB BW reduction to 5MHz for all DL/UL channels”, Format 0 is used for Rural scenario and Format B4 is used for Urban scenario

o   Format C2 can be used optionally.

Agreement

For Msg2 coverage evaluation of reference UE, Rel-17 RedCap UE, and Rel-18 RedCap UE, A TBS of 72 bits is assumed.

Final summary in R1-2205604, revised in R1-2205643.

9.6.33        Other

R1-2203119         Initial evaluation results for further RedCap UE complexity reduction   Ericsson

R1-2203340         Other considerations for eRedCap  Spreadtrum Communications

R1-2203475         Views on coexistence between Rel-17 and Rel-18 RedCap UE CATT

R1-2203574         Feature extension for Rel-18 Devices            vivo, Guangdong Genius

R1-2203602         Other aspects for Rel-18 eRedCap UE           ZTE, Sanechips

R1-2203829         Other aspects on further NR Redcap UE complexity reduction xiaomi

R1-2204040         On other aspects for RedCap evolution         Nokia, Nokia Shanghai Bell

R1-2204095         Early thoughts on Rel-18 RedCap UE features            FUTUREWEI

R1-2204317         Discussion on other aspects for RedCap UE CMCC

R1-2204917         Overall considerations for Rel-18 RedCap    Huawei, HiSilicon

 RAN1#110

9.6       Study on further NR RedCap (reduced capability) UE complexity reduction

Please refer to RP-221161 for detailed scope of the SI.

R1-2208317        Session notes for 9.6 (Study on further NR RedCap (reduced capability) UE complexity reduction)     Ad-hoc Chair (CMCC)    (rev of R1-2208148)

[110-R18-RedCap] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Johan (Ericsson)

R1-2207730         FL summary for collection of evaluation results for Rel-18 RedCap SI   Moderator (Ericsson, MediaTek)

R1-2207981         FL summary #2 for collection of evaluation results for Rel-18 RedCap SI               Moderators (Ericsson, MediaTek)

9.6.1        Potential solutions to further reduce UE complexity

R1-2205739         Potential solutions for further RedCap UE complexity reduction            Ericsson

R1-2205741         Analysis of complexity reduction techniques for RedCap UEs in Rel-18               FUTUREWEI

R1-2205873         Discussion on potential solutions to further reduce UE complexity         Huawei, HiSilicon

R1-2205997         Discussion on potential solutions to further reduce UE complexity         Spreadtrum Communications

R1-2206051         Techniques to further reduce RedCap UE complexity vivo, Guangdong Genius

R1-2206127         Complexity reduction for RedCap UEs         Sony

R1-2206201         Discussion on further RedCap UE complexity reduction           DENSO CORPORATION

R1-2206303         Solution study on further reduced UE complexity       OPPO

R1-2206333         Potential solutions to further reduce UE complexity for eRedCap           Panasonic

R1-2206409         Discussion on solutions to further reduce UE complexity in Rel-18        CATT

R1-2206417         Discussion on potential solutions to further reduce UE complexity         NEC

R1-2206443         Further RedCap UE Complexity Reduction  Nokia, Nokia Shanghai Bell

R1-2206494         On further complexity reduction of NR UE   Nordic Semiconductor ASA

R1-2206593         On solutions to further reduce UE complexity             Intel Corporation

R1-2206653         Potential solutions to further reduce UE complexity   Xiaomi

R1-2206672         Discussion  on potential solutions to further reduce UE complexity        Transsion Holdings

R1-2206695         Discussion on potential solutions to further reduce UE complexity         China Telecom

R1-2206836         Further UE complexity reduction for eRedCap            Samsung

R1-2206923         Discussion on further reduced  UE complexity            CMCC

R1-2206937         Discussion on solutions to further reduce UE complexity         Sharp

R1-2207002         Potential solutions to further reduce UE complexity   MediaTek Inc.

R1-2207036         Discussion on potential solutions for further UE complexity reduction  LG Electronics

R1-2207057         Discussion on eRedCap UE complexity reduction      ZTE, Sanechips

R1-2207148         On complexity reduction for RedCap UE      InterDigital, Inc.

R1-2207243         Further complexity reduction for eRedCap device      Qualcomm Incorporated

R1-2207260         Considerations for further UE complexity reduction   Sierra Wireless. S.A.

R1-2207477         Potential solutions to further reduce UE complexity   Lenovo

R1-2207684         Discussion on potential solutions for further UE complexity reduction for eRedCap               NTT DOCOMO, INC.       (rev of R1-2207416)

R1-2207731        FL summary #1 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From Monday session

Conclusion

Complexity reduction estimates are averaged as R17 over the results provided by the sourcing companies

Conclusion

The table formats used in the 7 tables with complexity reduction estimates for the BW options listed in the end of Section 7.2.2 in R1-2207731 are used as a baseline text for TR 38.865.

Note: values in the table may be updated

Conclusion

The table formats used in the 7 tables with complexity reduction estimates for the PR options listed in the end of Section 7.3.2 in R1-2207731 are used as a baseline text for TR 38.865.

Note: values in the table may be updated

Conclusion

The table format used in the table with complexity reduction estimates achieved by combinations of UE complexity reduction features listed in the end of Section 7.5.2 in R1-2207731 is used as a baseline text for TR 38.865.

Note 1: values in the table may be updated

R1-2207732        FL summary #2 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From Tuesday session

Agreement

Use the following TP on evaluation methodology as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

R1-2207733        FL summary #3 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

From Wed session

Conclusion

The values in the 7 tables with cost reduction estimates for the BW options listed in the end of Section 7.2.2 in R1-2207733, with FD-FDD 1Rx corrected average, are used as a baseline text for TR 38.865.

Conclusion

The values in the 7 tables with cost reduction estimates for the PR options listed in the end of Section 7.3.2 in R1-2207733, with FD-FDD 1Rx corrected average, are used as a baseline text for TR 38.865.

Conclusion

The values in the table with cost reduction estimates achieved by combinations of UE complexity reduction features in Section 7.5.2 in R1-2207733, with FD-FDD 1Rx corrected average, are used as a baseline text for TR 38.865.

Agreement

Use the following TP as baseline text for TR 38.865.

R1-2207734        FL summary #4 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

Agreement

·        Adopt the following TP as a baseline text for TR 38.865, clause7.3.2.

Agreement

Capture the following observations regarding UE complexity reduction from relaxed UE processing timeline option PT1 in TR 38.865, clause 7.4.2.

·        For the relaxed UE processing timeline option PT1, the cost reduction is mainly in the BB part, especially on receiver processing block, LDPC decoding, DL control processing & decoder, and UL processing block.

·        Whether the relaxed UE processing time in terms of N₁ and N₂ may reduce the cost/complexity in the 'DL control processing & decoder' block depends on the UE implementation.

Agreement

Capture the following observations regarding UE complexity reduction from relaxed UE processing timeline option PT2 in TR 38.865, clause 7.4.2.

·        For the relaxed UE processing timeline option PT2, the cost reduction is mainly in the BB part, especially on DL control processing & decoder when PT1 is supported, UL processing block, and MIMO specific processing blocks.

·        Whether the relaxed UE processing time in terms of Z and Z’ may reduce the cost/complexity in the 'DL control processing & decoder' block depends on the UE implementation.

Agreement

The highlighted impacts in R1-2207734 are adopted as starting point for TR input.

R1-2207982        FL summary #5 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.2.3:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.2.4:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.3.3:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.3.4:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.3.5:

Agreement

·        Adopt the following TP on performance impacts from relaxed UE processing timeline options as a baseline text for TR 38.865 clause 7.4.3.

Note: Note for power consumption and throughput is to be added by editor.

Agreement

·        Adopt the following TP on network deployment and coexistence impacts from relaxed UE processing timeline options as a baseline text for TR 38.865 clause 7.4.4.

Agreement

·        Adopt the following TP on specification impacts from relaxed UE processing timeline options as a baseline text for TR 38.865 clause 7.4.5.

Final (eom) summary in R1-2207983.

-----------------------------------------------Post-meeting--------------------------------------------------------

R1-2208273        FL summary #7 on potential solutions to further reduce RedCap UE complexity               Moderator (Ericsson)

Agreement

·        Adopt the following TP on evaluation methodology as baseline text for TR 38.865 clause 6.1.

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 7.2.5:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 9:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 9:

Agreement

·        Adopt the following TP as a baseline text for TR 38.865 clause 9:

Agreement

·        Adopt the following TP as a baseline text for Notes 1 and 2 in TR 38.865 clause 7.2.2.

Agreement

·        Adopt the following TP for removing “(Maximum UE channel bandwidth)” as baseline text for TR 38.865 clause 7.2.1.

Final summary in R1-2208287.

9.6.22        Evaluation of coverage impact

R1-2205874         Discussion on coverage evaluation Huawei, HiSilicon

R1-2205998         Evaluation of coverage impact for eRedCap Spreadtrum Communications

R1-2206052         Coverage evaluation for eRedCap   vivo, Guangdong Genius

R1-2206104         Discussion on NR RedCap UE coverage       Mavenir

R1-2206304         Evaluation of coverage for RedCap enhancement       OPPO

R1-2206410         Evaluation of coverage of Rel-18 eRedCap UEs         CATT

R1-2206437         Evaluation of coverage impact for eRedCap Panasonic

R1-2206444         Evaluation of coverage impact        Nokia, Nokia Shanghai Bell

R1-2206654         Evaluation of coverage impact of further UE bandwidth reduction         Xiaomi

R1-2206673         Discussion on simulation needs and assumptions        Transsion Holdings

R1-2206837         Coverage evaluations for eRedCap Samsung

R1-2206924         Discussion on evaluation of coverage impact              CMCC

R1-2207003         Evaluation of coverage impact for Rel-18 RedCap     MediaTek Inc.

R1-2207058         Coverage evaluation for eRedCap UE           ZTE, Sanechips

R1-2207149         Evaluation on coverage impact for RedCap UE           InterDigital, Inc.

R1-2207244         Coverage analysis for eRedCap       Qualcomm Incorporated

R1-2207478         Evaluation of coverage impact        Lenovo

R1-2207692         Discussion on evaluations of coverage impact for eRedCap      NTT DOCOMO, INC.               (rev of R1-2207417)

R1-2207740         Evaluations on coverage impact for eRedCap UE       Intel Corporation (rev of R1-2206594)

R1-2207741         Evaluation of coverage impact for further RedCap UE complexity reduction               Ericsson (rev of R1-2205740)

R1-2207904        Example tables for R18 eRedCap coverage impact evaluation          Moderator (MediaTek)

R1-2207866        FL summary #1 on evaluation of coverage impact Moderator (MediaTek)

From Monday session

Conclusion

For TR, for each evaluated deployment scenario, capture at least following three tables when the link budgets of evaluated channels of R18 eRedCap UE are compared to a bottleneck channel in the reference R15 NR UE:

·        The first table presents the bottleneck channel and its MIL value for the reference R15 NR UE

o   Note: See Table 8.2.1-[1] in R1-2207904 for an example

·        The second table and the third table present the coverage margins of evaluated channels for Rel-18 eRedCap UE without and with a 3dB antenna efficiency loss for Rel-18 eRedCap UE, respectively.

o   Note: The coverage margins of evaluated channels for Rel-18 eRedCap UE are relative to the bottleneck channel in the reference R15 NR UE.

o   Note: See the following example tables for the columns (i.e. evaluated channels) and rows of a table on coverage margins

§  Table 8.2.1-[2] (Part 1) and Table 8.2.1-[2] (Part 2) in R1-2207904

o   Table 8.2.1-[3] (Part 1) and Table 8.2.1-[3] (Part 2) in R1-2207904

Note: values in the table may be updated

Conclusion

For a table on coverage margins of evaluated channels in a deployment scenario,

·        the evaluated channels (listed in the columns) are the cases written all in black color in the coverage evaluation excel template agreed in R1-2205696 for the deployment scenario

o   Note: For example, for Urban at 2.6GHz with 11 PRBs, the evaluated channels for PDCCH CSS include

§  5 MHz RedCap UE (BW1, 11 PRBs; CORESET: 2 symbols, 48 PRBs; AL16),

§  5 MHz RedCap UE (BW1, 11 PRBs; CORESET: 2 symbols, 24 PRBs; AL8), and

§  [5 MHz RedCap UE (BW1, 11 PRBs; CORESET: 3 symbols, 6 PRBs; AL2).]

·        Note: See the following example tables for the columns (i.e. evaluated channels) and rows of a table on coverage margins

o   Table 8.2.1-[2] (Part 1) and Table 8.2.1-[2] (Part 2) in R1-2207904

o   Table 8.2.1-[3] (Part 1) and Table 8.2.1-[3] (Part 2) in R1-2207904

R1-2207867        FL summary #2 on evaluation of coverage impact Moderator (MediaTek)

From Tuesday session

Agreement

For a table on coverage margins of evaluated channels in a deployment scenario,

·        A representative value is not provided for coverage margin for an evaluated channel in a scenario if the number of samples is not greater than 3.

·        Note: Per agreements at RAN1 #109e and R17 RedCap SI, a representative value for the coverage margin of a channel in a scenario is derived by taking the mean value (in dB domain) from the coverage margin values from all sourcing companies, including both negative and non-negative values based on the following adjustments.

o   Excluding the highest & the lowest values when the number of samples is more than 3.

Agreement

For a table on coverage margins of evaluated channels in a deployment scenario,

·        The rows are composed of sourcing companies’ names, representative value 1, number of samples 1, representative value 2, and number of samples 2. For an evaluated channel (i.e an evaluated case listed in the column),

o   the representative value 1 is derived from the coverage margins only from sourcing companies who had provided uplink coverage evaluation results for the reference R15 NR UE

o   The number of samples 1 is the total number of sourcing companies that had provided uplink coverage evaluation results for the reference R15 NR UE

o   the representative value 2 is derived from the coverage margins from all sourcing companies regardless whether or one had provided uplink coverage evaluation results for the reference R15 NR UE

o   The number of samples 2 is the total number of all sourcing companies

Conclusion

For companies who did not submit results for uplink channels for the reference R15 NR UE, the following two options can be considered to determine a bottleneck channel and the corresponding MIL value for the reference R15 NR UE.

·        Option 1: Bottleneck channels and representative MIL values are determined from the following tables in Rel-17 RedCap SI TR38.875.

o   Table 9.1.1-1: Bottleneck channel and MIL value for Reference NR UE in Urban 2.6 GHz

o   Table 9.1.2-1: Bottleneck channel and MIL value for Reference NR UE in rural 0.7 GHz

o   FFS: Table 9.1.3-1: Bottleneck channel and MIL values for Reference NR UE in Urban 4 GHz

o   For each table above, a representative MIL value is derived by taking the mean value (in dB domain) from the MIL values from all sourcing companies after excluding the highest & the lowest values.

·        Option 2: Sourcing company to update their coverage results for uplink channels at least for R15 NR reference UE by CEST 11:59pm on Wednesday (24^th August).

Agreement

In Urban scenario at 2.6GHz (with 30 kHz SCS) with 11 PRB, capture the comparison of PBCH coverage difference between the potential Rel-18 UE and Rel-17 Redcap UE, as well as that between the potential Rel-18 UE and reference Rel-15 UE.

·        Note: Soft/selective combining can utilize up to 4 PBCH repetitions

Agreement

In Rural scenario at 0.7 GHz and Urban scenario at 2.6GHz, capture the comparisons of PDCCH CSS and SIB1 coverage differences between the potential Rel-18 UE and Rel-17 Redcap, as well as those between the potential Rel-18 UE and reference Rel-15 UE.

·        Note: One shot decoding is assumed as per agreed configuration

Table 6.2-5a-1: Urban scenario at 2.6GHz (30 kHz SCS)

Table 6.2-5a-2: Rural scenario at 0.7 GHz (15 kHz SCS)

R1-2207868        FL summary #3 on evaluation of coverage impact Moderator (MediaTek)

From Wed session

Conclusion

Confirm that Table 9.1.3-1 of TR38.875: bottleneck channel and its representative MIL value can be used for Urban at 4GHz in Option 1.

Agreement

Support to keep the following PDCCH CSS case in the tables of coverage margins

·        PDCCH CSS (BW1, 11 PRB, CORESET: 3 symbols, 6 PRBs; AL2)

·        Note: In TS 38.211, it is specified that the number of RBs of CORESET 0 should be a multiple of (REG bundle size X interleaving size). This CORESET with 6PRBs and 3symbols hence does not align with current specification. Companies are encouraged to explain what assumptions they had made for the evaluation.

Agreement

For Urban scenario at 2.6GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.1.

“For Urban scenario at 2.6GHz, PUSCH is the bottleneck channel for the reference R15 NR UE.”

Agreement

For Urban scenario at 2.6GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.1

Note: the TP will be updated according to final evaluation results.

R1-2207869        FL summary #4 on evaluation of coverage impact Moderator (MediaTek)

Agreement

Adopt the following tables from R1-2207869 to clause 8.2 of TR 38.865:

·        Table 8.2.1-1: Bottleneck channels and MIL values for the reference R15 NR UE in Urban scenario at 2.6GHz

·        Table 8.2.1-2 (part 1 and part 2): In Urban scenario at 2.6GHz with DL 33dBm/MHz PSD, coverage margins for the potential Rel-18 UE with maximum 11-PRB bandwidth compared to the bottleneck channel for the reference NR UE in Table 8.2.1-1 when no UE antenna efficiency loss is assumed for the potential Rel-18 UE.

·        Table 8.2.1-3 (part 1 and part 2): In Urban scenario at 2.6GHz with DL 33dBm/MHz PSD, coverage margins for the potential Rel-18 UE with maximum 11-PRB bandwidth compared to the bottleneck channel for the reference NR UE in Table 8.2.1-1 when 3dB UE antenna efficiency loss is assumed for the potential Rel-18 UE.

·        Table 8.2.1-4 (part 1 and part 2): In Urban scenario at 2.6GHz with DL 33dBm/MHz PSD, coverage margins for the potential Rel-18 UE with maximum 12-PRB bandwidth compared to the bottleneck channel for the reference NR UE in Table 8.2.1-1 when no UE antenna efficiency loss is assumed for the potential Rel-18 UE.

·        Table 8.2.1-5 (part 1 and part 2): In Urban scenario at 2.6GHz with DL 33dBm/MHz PSD, coverage margins for the potential Rel-18 UE with maximum 12-PRB bandwidth compared to the bottleneck channel for the reference NR UE in Table 8.2.1-1 when 3dB UE antenna efficiency loss is assumed for the potential Rel-18 UE.

Note: the tables 8.2.2-x, 8.2.3-x from R1-2207869 are adopted in principle for the TR38.865 input.

Agreement

·        For Urban scenario at 2.6GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.1

Agreement

·        For Urban scenario at 2.6GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.1

Agreement

·        The following TP is adopted as a baseline to TR 38.865, applicable to clause 8.2.1, 8.2.2, 8.2.3, and 8.2.4.

Agreement

·        For Rural scenario, the following TP is adopted as a baseline to TR 38.865, clause 8.2.2

Agreement

·        For Urban scenario at 4GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.3

Agreement

·        For Urban scenario at 4GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.3

Agreement

·        For Urban scenario at 4GHz, the following TP is adopted as a baseline to TR 38.865, clause 8.2.3

Agreement

·        Adopt the following TP as a baseline text for TR 38.865, clause 6.2.

Agreement

·        Adopt the following TP as a baseline text for TR 38.865.

R1-2207905        FL summary #5 on evaluation of coverage impact Moderator (MediaTek)

Agreement

·        Adopt the following table and observations as baseline text to clause 8.2.1 in TR 38.865

Note: Companies can update the table before Friday’s lunch break

Agreement

·        Adopt the following Table 8.2.1-7 and observations as baseline text to clause 8.2.1 of TR 38.865

Final (eom) summary in R1-2208245.

-----------------------------------------------Post-meeting--------------------------------------------------------

Agreement

·        Adopt the following TP as a baseline text for the Coverage part in TR 38.865 clause 7.2.3:

Agreement

·        Adopt the following TP as a baseline text for the Coverage part in TR 38.865 clause 7.3.3:

Agreement

Regarding the case of PDCCH CSS with AL8 and 24 PRBs, remove it from Table 8.2.1-7 for the Urban scenario at 2.6GHz (with 11 PRBs) while it is kept in Table 8.2.2-6 for the Rural scenario (with 25 PRBs).

Agreement

·        Adopt the following TP as a baseline text to Clause 8.2.1 of TR38.865

Agreement

·        Adopt the following TP as a baseline text to Clause 8.2.1 of TR38.865

Agreement

·        Adopt the following TP as a baseline text to Clause 8.2.1 of TR38.865

Agreement

·        Adopt the following TP as a baseline text to Clause 8.2.1 of TR38.865

Agreement

·        Adopt the following TP as a baseline text to Clause 8.2.2 of TR38.865

Agreement

·        Adopt the following TP and table as baseline text to Clause 8.2.2 of TR38.865

Agreement

·        Adopt the following TP as a baseline text for clause 8.2.4 in TR 38.865

Agreement

·        Adopt the following TP as a baseline text for clause 8.2.4 in TR 38.865

Agreement

·        Adopt the following TP and table as a baseline text for clause 8.2.4 in TR 38.865

Agreement

·        Adopt the following TP as a baseline text for clause 8.2.4 in TR 38.865

Final summary in R1-2208288        FL summary #7 on evaluation of coverage impact      Moderator (MediaTek)

 RAN1#110-bis-e

9.6       Enhanced support of reduced capability NR device

Please refer to RP-222675 for detailed scope of the WI.

R1-2210693        Session notes for 9.6 (Study on further NR RedCap (reduced capability) UE complexity reduction)     Ad-hoc Chair (CMCC)

R1-2208361         WI work plan for Rel-18 RedCap   Rapporteur (Ericsson)

R1-2210637         RAN1 agreements for Rel-18 NR RedCap    Rapporteur (Ericsson)

9.6.11        UE complexity reduction

R1-2210283         Further RedCap UE complexity reduction    Ericsson (rev of R1-2208362)

R1-2208387         Discussion on details for R18 RedCap complexity techniques  FUTUREWEI

R1-2208416         Discussion on potential solutions to further reduce UE complexity         Huawei, HiSilicon

R1-2208560         Discussion on enhanced support of RedCap devices   Spreadtrum Communications

R1-2208653         Discussion on UE further complexity reduction          vivo, Guangdong Genius

R1-2208775         Discussion on UE complexity reduction        China Telecom

R1-2208842         Technologies for further reduced UE complexity        OPPO

R1-2208986         Discussion on further complexity reduction for eRedCap UE   CATT

R1-2209004         RedCap UE Complexity Reduction Nokia, Nokia Shanghai Bell

R1-2209062         Discussion on complexity reduction for eRedCap UE Intel Corporation

R1-2209109         UE complexity reduction for eRedCap          Sony

R1-2209163         Discussion on Rel-18 RedCap UE   NEC

R1-2209170         Discussion on UE complexity reduction        Transsion Holdings

R1-2209194         Discussion on further UE complexity reduction          ZTE, Sanechips

R1-2209221         UE complexity reduction  Lenovo

R1-2209295         Discussion on further complexity reduction for eRedCap UEs  xiaomi

R1-2209347         Discussion on further UE complexity reduction          CMCC

R1-2209451         Discussion on further UE complexity reduction for eRedCap   LG Electronics

R1-2209519         On further UE complexity reduction for RedCap        MediaTek Inc.

R1-2209663         Considerations for further UE complexity reduction   Sierra Wireless. S.A.

R1-2209684         Discussion on UE complexity reduction        Sharp

R1-2209741         Further UE complexity reduction for eRedCap            Samsung

R1-2209791         UE complexity reduction for eRedCap          Panasonic

R1-2209866         Discussion on UE complexity reduction        DENSO CORPORATION

R1-2209912         Discussion on further UE complexity reduction for eRedCap   NTT DOCOMO, INC.

R1-2209995         UE complexity reduction for eRedCap          Qualcomm Incorporated

R1-2210196         On further complexity reduction of NR UE   Nordic Semiconductor ASA

R1-2209591         Discussion on further RedCap UE complexity reduction           Apple

[110bis-e-R18-RedCap-01] – Johan (Ericsson)

Email discussion on further UE complexity reduction by October 19

-        Check points: October 14, October 19

R1-2210248        FL summary #1 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Oct 10th GTW session

Agreement

For a cell supporting both Rel-17 and Rel-18 RedCap UEs,

·        The Rel-18 RedCap UEs can share the same separate initial DL/UL BWP as the Rel-17 RedCap UEs.

·        FFS: whether to support an additional separate initial DL/UL BWP specific to Rel-18 RedCap UEs

Agreement (further amended on Oct 17th as shown below)

For UE BB bandwidth reduction, for SIB1 (PDSCH) to Rel-18 RedCap UEs, down-select between the following options:

• Option 1: Restrict the scheduling of SIB1 to be within 5 MHz
• Option 2: Allow the scheduling of SIB1 to be larger than 5 MHz (as in legacy operation)
• FFS: whether 5MHz is assumed to be physically contiguous

R1-2210249        FL summary #2 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Oct 12th GTW session

Agreement (further amended on Oct 17th as shown below)

For UE BB bandwidth reduction, for PUSCH, down-select between the following options for the maximum number of PRBs that the UE can transmit:

·        Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS

·        Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS

·        Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

·        Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

For UE BB bandwidth reduction, for PDSCH (at least for unicast), down-select between the following options for the maximum number of PRBs that the UE can [receive/process]:

·        Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS

·        Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS

·        Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

·        Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

Same option will be selected for both PDSCH (at least for unicast) and PUSCH.

Agreement (further amended on Oct 19th as shown below)

For UE BB bandwidth reduction, for paging channel (PDSCH) to Rel-18 RedCap UEs, down-select between the following options:

·        Option 1: Restrict the scheduling of paging channel to be within 5 MHz

·        Option 2: Allow the scheduling of paging channel to be larger than 5 MHz (as in legacy operation)

·        FFS: whether 5MHz is assumed to be physically contiguous

Agreement

For UE BB bandwidth reduction, for broadcast OSI (PDSCH) to Rel-18 RedCap UEs, down-select between the following options:

·        Option 1: Restrict the scheduling of OSI PDSCH to be within 5 MHz

·        Option 2: Allow the scheduling of OSI PDSCH to be larger than 5 MHz (as in legacy operation)

·        FFS: whether 5MHz is assumed to be physically contiguous

For UE BB bandwidth reduction, for RAR (PDSCH) to Rel-18 RedCap UEs, down-select between the following options:

·        Option 1: Restrict the scheduling of RAR PDSCH to be within 5 MHz

·        Option 2: Allow the scheduling of RAR PDSCH to be larger than 5 MHz (as in legacy operation)

·        FFS: whether 5MHz is assumed to be physically contiguous

Agreement

·        UE peak data rate reduction is supported at least as an add-on to UE BB bandwidth reduction,

o   The constraint v_Layers·Q_m·f ≥ 4 is relaxed to v_Layers·Q_m·f ≥ X.

o   FFS: the value of X

·        If UE peak data rate reduction is supported as a standalone feature,

o   The constraint v_Layers·Q_m·f ≥ 4 is relaxed to v_Layers·Q_m·f ≥ Y.

o   FFS: the value of Y

o   Note: Whether this option is supported will be decided in RAN plenary.

R1-2210250        FL summary #3 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Oct 17th GTW session

Agreement

Replace the agreement on the maximum number of PRBs supported by UE with the following:

For UE BB bandwidth reduction, for PUSCH, down-select between the following options for the maximum number of PRBs that the UE can transmit per slot or per hop, if applicable:

o   Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS

o   Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS

o   Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

o   Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

For UE BB bandwidth reduction, for PDSCH (at least for unicast), down-select between the following options for the maximum number of PRBs that the UE can process per slot:

o   Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS

o   Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS

o   Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

o   Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

Same option will be selected for both PDSCH (at least for unicast) and PUSCH.

Agreement

Replace the agreement on SIB1(PDSCH) for UE BB bandwidth reduction with the following:

For UE BB bandwidth reduction, for SIB1 (PDSCH),

o   Allow the scheduling of SIB1 to be larger than 5 MHz (as in legacy operation)

o   FFS: UE post-FFT buffering “assumption”

Agreement

For UE BB bandwidth reduction, a UE is not expected to receive an UL grant in a DCI with a PUSCH resource allocation spanning a bandwidth of more than ~5 MHz per slot or per hop, if applicable.

R1-2210251        FL summary #4 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Oct 19th GTW session

Agreement

Replace the agreement on broadcast OSI (PDSCH) for UE BB bandwidth reduction with the following:

For UE BB bandwidth reduction, for broadcast OSI (PDSCH),

·        Allow the scheduling of broadcast OSI (PDSCH) to be larger than 5 MHz (as in legacy operation)

Agreement

•         For UE BB bandwidth reduction, a UE is not expected to be configured with a CG grant with a PUSCH resource allocation spanning a bandwidth of more than ~5 MHz per slot or per hop, if applicable.

•         For UE BB bandwidth reduction, it is FFS whether a UE can be expected to receive an UL grant in a RAR with a Msg3 PUSCH resource allocation spanning a bandwidth of more than ~5 MHz per slot or per hop, if applicable.

 RAN1#111

9.6       Enhanced support of reduced capability NR device

Please refer to RP-222675 for detailed scope of the WI.

R1-2212848        Session notes for 9.6 (Study on further NR RedCap (reduced capability) UE complexity reduction)     Ad-hoc Chair (CMCC)

Endorsed and contents incorporated below.

[111-R18-RedCap] – Johan (Ericsson)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

For information

R1-2212982         RAN1 agreements for Rel-18 NR RedCap    Rapporteur (Ericsson)

9.6.11        UE complexity reduction

R1-2210833         Continued discussion on R18 RedCap complexity techniques  FUTUREWEI

R1-2210868         Discussion on potential solutions to further reduce UE complexity         Huawei, HiSilicon

R1-2211017         Discussion on UE further complexity reduction          vivo, Guangdong Genius

R1-2211099         UE complexity reduction for eRedCap          Panasonic

R1-2211208         Discussion on further complexity reduction for eRedCap UE   CATT

R1-2211240         Discussion on enhanced support of RedCap devices   Spreadtrum Communications, H3C

R1-2211372         Discussion on further complexity reduction for eRedCap UEs  xiaomi

R1-2211409         Discussion on complexity reduction for eRedCap UE Intel Corporation

R1-2211470         Technologies for further reduced UE complexity        OPPO

R1-2211517         Discussion on UE complexity reduction        Transsion Holdings

R1-2211531         Discussion on UE complexity reduction        China Telecom

R1-2211571         UE complexity reduction  Lenovo

R1-2211620         UE complexity reduction for eRedCap          Sony

R1-2211690         Discussion on further UE complexity reduction          CMCC

R1-2211757         Further RedCap UE complexity reduction    Ericsson

R1-2211759         RedCap UE Complexity Reduction Nokia, Nokia Shanghai Bell

R1-2211820         Further RedCap UE complexity reduction    Apple

R1-2211850         Considerations for further UE complexity reduction   Sierra Wireless. S.A.

R1-2211856         Discussion on UE complexity reduction        Sharp

R1-2211875         Discussion on Rel-18 RedCap UE   NEC

R1-2211902         Discussion on further UE complexity reduction          ZTE, Sanechips

R1-2211993         Discussion on further UE complexity reduction for eRedCap   NTT DOCOMO, INC.

R1-2212055         Further UE complexity reduction for eRedCap            Samsung

R1-2212127         UE complexity reduction for eRedCap          Qualcomm Incorporated

R1-2212175         Discussion on UE complexity reduction        DENSO CORPORATION

R1-2212246         On eRedCap UE complexity reduction          MediaTek Inc.

R1-2212300         Discussion on further UE complexity reduction for eRedCap   LG Electronics

R1-2212416         On further complexity reduction of NR UE   Nordic Semiconductor ASA

R1-2212533        FL summary #1 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Nov 14th session

Conclusion

For UE BB complexity reduction, for broadcast and unicast PDSCH, RAN1 does not assume that the UE post-FFT buffer size per slot is smaller than 20 MHz.

Agreement

From RAN1 perspective, for UE BB complexity reduction, for paging channel (PDSCH) to Rel-18 RedCap UEs, allow the scheduling of paging channel to be larger than 5 MHz (as in legacy operation).

Agreement

For UE BB complexity reduction, a UE is not expected to receive an UL grant in a RAR or in a DCI scrambled with TC-RNTI with a Msg3 PUSCH resource allocation spanning a bandwidth of more than ~5 MHz per slot or per hop, if applicable.

R1-2212534        FL summary #2 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Nov 16th session

Agreement

For UE BB bandwidth reduction, for RAR (PDSCH) to Rel-18 RedCap UEs, the scheduling of RAR PDSCH is allowed to be larger than the maximum number of unicast PRBs that the UE can process per slot.

• When the scheduling of RAR PDSCH is within the maximum number of unicast PRBs that the UE can process per slot, the legacy time between RAR reception and Msg3 transmission (not smaller than N_T,1 + N_T,2 + 0.5 ms) is applied.
• When the scheduling of RAR PDSCH is larger than the maximum number of unicast PRBs that the UE can process per slot,

o   The UE receives the RAR and correspondingly transmits Msg3 if the TDRA for Msg3 in UL grant in RAR indicates that the time between RAR reception and Msg3 transmission is NOT smaller than N_T,1 + N_T,2 + 0.5 + X ms.

§  FFS: value(s) of X

o   Otherwise, the UE behavior is up to the UE implementation.

·        Note: it does not mean early indication is needed

·        Note: it will not be used as example for unicast PDSCH

Agreement

For UE BB complexity reduction, a UE is able to receive a DL assignment in a DCI with a unicast PDSCH resource allocation spanning a bandwidth of more than ~5 MHz per slot.

The number of PRB scheduled in DCI is not larger than the maximum number of PRB agreed in previous agreement from 110b-e

Agreement

For UE BB bandwidth reduction, for PUSCH, down-select between the following options for the maximum number of PRBs that the UE can transmit per slot or per hop, if applicable:

• Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS
• Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

For UE BB bandwidth reduction, for PDSCH (for both unicast and broadcast), down-select between the following options for the maximum number of PRBs that the UE can process per slot:

• Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS
• Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

Same option will be selected for both PDSCH and PUSCH.

Conclusion

For UE BB complexity reduction, broadcast of separate SIB1/OSI (PDSCH) to Rel-18 RedCap UEs is not supported.

R1-2212535        FL summary #3 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Nov 17th session

Agreement

• The minimum DL peak rate target (for FD-FDD) is [10] Mbps based on peak data rate calculation according to 38.306.
• The same value for X is used for DL and UL

Final summary in R1-2212536.

 RAN1#112

9.6       Enhanced support of reduced capability NR device

Please refer to RP-223544 for detailed scope of the WI.

R1-2302066        Session notes for 9.6 (Study on further NR RedCap (reduced capability) UE complexity reduction)     Ad-hoc Chair (CMCC)

[112-R18-RedCap] – Johan (Ericsson)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2300177         WI work plan for Rel-18 RedCap   Rapporteur (Ericsson)

R1-2301885         RAN1 agreements for Rel-18 NR RedCap    Rapporteur (Ericsson)

9.6.11        UE complexity reduction

R1-2300058         Discussion on R18 RedCap complexity techniques     FUTUREWEI

R1-2300114         Discussion on potential solutions to further reduce UE complexity         Huawei, HiSilicon

R1-2300229         Discussion on enhanced support of RedCap devices   Spreadtrum Communications, New H3C

R1-2300272         Further consideration on reduced UE complexity        OPPO

R1-2300371         Discussion on further UE complexity reduction          ZTE, Sanechips

R1-2300464         Discussion on further UE complexity reduction          vivo

R1-2300500         Further RedCap UE complexity reduction    Ericsson

R1-2300586         Discussion on further complexity reduction for eRedCap UEs  xiaomi

R1-2300691         Discussion on further complexity reduction for Rel-18 RedCap UE        CATT

R1-2300794         Discussion on UE complexity reduction        Sharp

R1-2300852         UE complexity reduction for eRedCap          Panasonic

R1-2300855         Discussion on Rel-18 RedCap UE   NEC

R1-2300858         UE complexity reduction  Lenovo

R1-2300884         UE complexity reduction for eRedCap          Sony

R1-2300959         Discussion on complexity reduction for eRedCap UE Intel Corporation

R1-2301772         Discussion on further reduced UE complexity             CMCC   (rev of R1-2301013)

R1-2301078         Discussion on UE complexity reduction        DENSO CORPORATION

R1-2301106         Discussion on further UE complexity reduction for eRedCap   LG Electronics

R1-2301149         RedCap UE Complexity Reduction Nokia, Nokia Shanghai Bell

R1-2301188         Considerations for further UE complexity reduction   Sierra Wireless. S.A.

R1-2301874         On further complexity reduction of NR UE   Nordic Semiconductor ASA            (rev of R1-2301193)

R1-2301275         Further UE complexity reduction for eRedCap            Samsung

R1-2301309         Discussion on UE complexity reduction        Transsion Holdings

R1-2301357         Further RedCap UE Complexity Reduction  Apple

R1-2301424         UE complexity reduction for eRedCap          Qualcomm Incorporated

R1-2301504         Discussion on further UE complexity reduction for eRedCap   NTT DOCOMO, INC.

R1-2301783         On eRedCap UE complexity reduction          MediaTek Inc.     (rev of R1-2301609)

R1-2301886        FL summary #1 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Tuesday session

Agreement

Revise the earlier agreement by removing the square brackets like this:

• The minimum DL peak rate target (for FD-FDD) is [10] Mbps based on peak data rate calculation according to 38.306.
• The same value for X is used for DL and UL

Agreement

For UE BB bandwidth reduction, for PUSCH, select the following option for the maximum number of PRBs that the UE can transmit per slot or per hop, if applicable:

• Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

For UE BB bandwidth reduction, for PDSCH (for both unicast and broadcast), select the following option for the maximum number of PRBs that the UE can process per slot:

• Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS

Note: No intention to change the RAN4 RF specifications about maximum transmission PRB number

R1-2301887        FL summary #2 on Rel-18 RedCap UE complexity reduction            Moderator (Ericsson)

From Wednesday session

Agreement

For the earlier RAN1 agreement achieved in RAN1#111 as following,

For UE BB bandwidth reduction, for RAR (PDSCH) to Rel-18 RedCap UEs, the scheduling of RAR PDSCH is allowed to be larger than the maximum number of unicast PRBs that the UE can process per slot.

• When the scheduling of RAR PDSCH is within the maximum number of unicast PRBs that the UE can process per slot, the legacy time between RAR reception and Msg3 transmission (not smaller than N_T,1 + N_T,2 + 0.5 ms) is applied.
• When the scheduling of RAR PDSCH is larger than the maximum number of unicast PRBs that the UE can process per slot,
• The UE receives the RAR and correspondingly transmits Msg3 if the TDRA for Msg3 in UL grant in RAR indicates that the time between RAR reception and Msg3 transmission is NOT smaller than N_T,1 + N_T,2 + 0.5 + X ms.
• FFS: value(s) of X

o   Otherwise, the UE behavior is up to the UE implementation.

• Note: it does not mean early indication is needed
• Note: it will not be used as example for unicast PDSCH

For the “FFS: value(s) of X”

• X = [0.5/0.25 or 1/0.5 or 2/1] ms for 15/30kHz SCS
• Note: Single Value pair for X is to selected for SCSs

Conclusion

There is no consensus to continue discussion on “whether additional separate initial DL/UL BWP specific to Rel-18 RedCap UEs is allowed to be configured by the SIB in the cell”.

Conclusion

For UE BB complexity reduction, there is no need to relax the requirements on simultaneous reception of two broadcast PDSCH transmissions for SIB1/OSI/paging/RAR.

Agreement

For the relaxed constraint X in the following earlier RAN1 agreement, down-select between X = 3 and X = 3.2.

Agreement

Update the agreement for PDSCH paging with the clarification as follows:

• From RAN1 perspective, for UE BB complexity reduction, for paging channel (PDSCH) to Rel-18 RedCap UEs, allow the scheduling of paging channel to be larger than 5 MHz (as in legacy operation). The scheduling of paging PDSCH is allowed to be larger than 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS.

Agreement